home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Cream of the Crop 21
/
Cream of the Crop 21 (Terry Blount) (October 1996).iso
/
printer
/
pshare.zip
/
README.TXT
< prev
next >
Wrap
Text File
|
1996-07-19
|
9KB
|
192 lines
PSHARE V1 shares printers across IPX network without Novell.
PSHARE is a print utility which provides shared use of one or more
printers across an IPX network. It utilizes a 5k DOS TSR on each client
workstation and does not require a Novell file server or software other
than the PSHARE programs & network drivers. The PSHARE server program
runs on a PC to which the shared printer is attached. It queues, then
spools, print jobs sent by the clients. An automatic upgrade option is
built in; if the client program is upgraded, the server can field the
upgrade to all users without use of any shared directories. Printing
from Windows 3.x is supported.
PSHARE is written in Microsoft C 6.0 & assembly and runs under DOS. It
requires Novell IPX drivers to be loaded, but uses only IPX/SPX and
never requires any Novell file server resources or the user to be logged
in.
Server side: (PSS.EXE): This collects the jobs sent by all the PSC
installations, queues & prints them.
1. Running PSS
PSS requires one parameter; the name you want to assign to it. It
is best run by your AUTOEXEC.BAT, after the network drivers are loaded.
Although PSS will work in DOS box under Windows, generally it will be
better to run it on a stand-alone PC to which the shared printers are
attached. (Some old, funcky 286 is fine, we're using a PS/2 70). PSS
uses only disk space for the queued files and conventional memory for
buffers. PSS doesn't use EMS, DPMI, XMS or graphics. By default, PSS
uses direct port I/O when printing, supplying /B on the command line
will force use of slower BIOS writes.
2. PSS Printer ports
PSS will support redirection to LPT1 thru LPT3 only. If a printer
is not attached to a port to which a job is sent, the job will just sit
there waiting for a printer ready signal. If PSS is run in a DOS box
under Windows 3.x, you may experience character loss (by virtue of how
Windows operates the DOS box).
3. Job Control
PSS offers no job control options, (ie: pausing, canceling jobs),
BUT if PSC stops sending (rebooted PC, for example), after a minute or
so, PSS will assume something happened, and will kill the job.
Client side: (PSC.EXE): Run on each PC which will use the shared
printer(s).
1. Running PSC
PSC requires a couple parameters to run; first the name of the PSS
instance to which it will attach, and the local LPT to remote LPT
assignments. The client PC has LPT1 thru LPT3, as does the PSS machine.
By specifying Lx=Ry; where x represents the client PC port (L
representing Local) and y represents the server PC port (R representing
Remote), you assign local ports to remote ports. At least one
assignment is required, but you're don't have to use LPT1 first. Run
PSC without parameters to see the command line help. At this time, PSC
cannot concurrently connect to printers on more than one PSS server.
2. General
When PSC is run & the parameters found valid, it tries to find the
PSS instance to which it is supposed to attach, then it connects and the
PSC version is checked. If it is old, PSS transmits a copy of the new
version to PSC, which writes it out to disk and exits with return code
255. If PSC is run from a batch file, the ERRORLEVEL function can test
for this, loop and re-run PSC. The PSC version is then OK, and PSC can
proceed. Once the version is resolved, PSC installs itself, leaving the
5k TSR resident. The resident portion is what redirects the printer
output. PSC picks off data sent via INT 17h, builds buffers and
transmits them via IPX to PSS where they are spooled to a file. PSC &
PSS use basic flow control to handle packet loss & duplication. Once a
job has started, if there is no data sent to INT 17h for a given time
period, PSC considers the job done and commits it. PSS then queues the
file and spools the job to the printer. Unfortunately there is no
attractive way I know of to detect the end of print jobs at the BIOS
level, so the timeout is the mechanism. If you start printing a new job
before the timeout expires, your new job will be added to the end of the
previous one, giving you a single bigger job. (Might print OK, might
not). The timeout is about 15 seconds, and is hardcoded (via #define).
Jobs can be sent concurrently via any combination of the 3 local LPT
ports, and they will not interfere with each other.
3. Interaction w/ other printer redirectors
If PSC receives INT 17h data, and is not already redirecting a
job, it calls down into the INT 17h chain to find the port status. If a
local printer is online or a lower-level driver is redirecting that
port, a result code is returned indicating the printer is ready. PSC
will then pass data directly down the chain without redirecting, until
the job is completed. If drivers higher in the INT 17h chain are
redirecting, the data will never reach PSC so PSC doesn't do anything.
This way, if CAPTURE, for example, redirects a particular port, it will
override PSC until the CAPTURE is removed. Similarly, if your local
port has an AB switch, you'll print locally when the switch is in your
position, and to the PSS printer when not. Ports not redirected by PSC
are not affected by PSC's presence. PSC always returns a printer ready
status when queried via INT 17h. If PSS isn't ready for the job, or
stops receiving part way through, PSC will timeout after a while and
return a printer error via the printer status code.
4. PSC under Windows 3.x
PSC will redirect the Windows print output just as in DOS. You
might consider enabling Print Manager so pauses in printing won't cause
the job to be prematurely committed.
5. Auto-Upgrade issues
This option is relevant if you modify PSC and want the updates
fielded to the user workstations. Compile PSC & PSS and put both
executables on the PSS server machine, in the same directory. Run PSS
from the directory where it is located. Then when the users connect,
they will be automatically upgraded by PSS. No hassle! If you write
protect the user PC copies of PSC, the upgrade will fail, and PSC will
start anyway (the old version, of course). PSC.EXE must exist in the
directory from which it is run for the upgrade to work. Obviously the
autoupgrade feature could easily spread a virus if your new PSC version
on the PSS machine became infected.
6. Unloading PSC
PSC can be unloaded once it is resident by running it again,
without parameters. It will check for re-hooked interrupts, and if
there are none, it will unload itself. When unloading, PSC will
immediately commit any jobs waiting on the job complete timeout.
Techie stuff:
1. You might experience some trouble with the TLI functions (they are a
wrapper around SPX, which PSHARE uses for the autoupgrade), particularly
in terms of opening/binding endpoints in PSS. I'm not sure why this is,
but appears related to the size of the app's near heap (data segment -
stack)- larger near heaps cause the app to generally work better than
smaller. The far heap size appears to not matter very much. A while
back, Novell offered free tech support via email; I used it and they
couldn't give me any hints other than the obvious ones.
2. PSS uses SAP to indicate its presence on the network. PSC does a
SAP query (not a Bindery or NDS query) to find PSS and consequently
doesn't require Novell file servers for anything. I didn't use the
Novell SDK versions of the SAP advertising or querying functions because
I wanted to query based on server name and type, which you can't do with
the canned Novell functions. Although I haven't tested this, you should
be able to have multiple PSS servers (with unique names). PSC should
find the one indicated on its command line, by name. The server type
values are hard-coded (using #define), so they can be redefined if
necessary.
PSHARE is fully public domain, and may be distributed in any form.
I wrote this program because my offi